Database systems are critical parts of many businesses. Typically, a database system generates redo logs, which records operations belonging to a stream of transactions performed by the database system. The mining of redo logs can be utilized in a variety of ways. For instance, a mined redo log can be utilized for replication, auditing, asynchronous event deliveries, asynchronous change data capture, and database restoration.
A mining process for the redo logs can be restarted due to various reasons. To limit the amount of a redo log that must be read, the mining process utilizes checkpoints. The checkpoints are recorded outside the redo logs and each checkpoint corresponds to a specific position in the redo log. A checkpoint represents a point in the transaction stream and provides access to data that permits a redo log to be read beginning at the checkpoint. Thus, when the mining process restarts after a failure or being stopped by users, it does not need to read the redo logs from the beginning of open transactions, but may instead begin at the first checkpoint preceding the failure and generate logical change records for distributed information sharing.
A simple way of making a checkpoint is to save data at the checkpoint which represents the current state of all transactions that are active, e.g., uncommitted, when the checkpoint is made. In a system that handles a large number of transactions, making such a checkpoint is expensive both as regards to the time required to make the checkpoint and as regards to the checkpoint's size. Over time, checkpoint management becomes more difficult as the checkpoints grow in number and consume an increasing amount of disk storage. As such, during restart, it can take the mining process quite sometime to figure out which checkpoint to use for restart. Periodic purging of large amount of checkpoint data also consumes significant system resource.
Therefore, a better mechanism, which would better support distributed information sharing through log mining, is needed.